Summary

Adds an optional with_io_runtime(handle) builder method to PostgresConnectionPool, allowing callers to route connection acquisition (and the background socket-IO task that bb8 spawns internally) onto a dedicated tokio IO runtime.

This is the IO runtime segregation follow-up noted in #548.

Problem

When a query engine runs DataFusion plans and Postgres IO on the same tokio runtime, CPU-bound work (plan optimization, aggregation, shuffles) starves IO tasks, causing connection timeouts, health-check failures, and unpredictable tail latency. This is the same class of issue fixed in #450 (non-blocking connection check), but at the connection-pool level rather than the DNS-lookup level.

Solution

• Add io_handle: Option<Handle> to PostgresConnectionPool
• Add with_io_runtime(handle: Handle) -> Self builder method
• When present, pool.get_owned() is dispatched via handle.spawn(...) so the connection and its background task land on the IO runtime
• When absent, behavior is identical to today (run_async_with_tokio / direct .await)

The returned Client communicates with its background task via channels, so it works correctly from any runtime after acquisition.

Why this pattern

DataFusion's own documentation explicitly recommends runtime segregation:

"If your system does not fully utilize either the CPU or network bandwidth during execution, or you see significantly higher tail (e.g. p99) latencies responding to network requests, it is likely you need to use a different Runtime for DataFusion plans."

— datafusion/core/src/lib.rs § Thread Scheduling

The pattern of accepting an optional Handle at construction time is converging across the ecosystem:

Changes

• core/src/sql/db_connection_pool/postgrespool.rs
  • New error variant IoRuntimeError (wraps tokio::task::JoinError)
  • New field io_handle: Option<Handle> on PostgresConnectionPool
  • New builder method with_io_runtime(handle)
  • connect() and connect_direct() dispatch through the handle when present
• core/tests/postgres/mod.rs
  • Integration test that creates a separate multi-thread IO runtime, constructs a pool with with_io_runtime(), and runs a query end-to-end

Usage

// Create a dedicated IO runtime
let io_runtime = tokio::runtime::Builder::new_multi_thread()
    .worker_threads(4)
    .enable_all()
    .build()?;

// Pass the handle to the pool — all connection background tasks
// will now run on io_runtime instead of the caller's runtime
let pool = PostgresConnectionPool::new(params)
    .await?
    .with_io_runtime(io_runtime.handle().clone());

Without with_io_runtime(), behavior is unchanged.

Test plan

• cargo build --features postgres compiles
• New test_postgres_io_runtime_segregation integration test verifies the IO-handle path end-to-end
• Existing tests unaffected (no behavioral change when io_handle is None)